Build securedrop-admin-dom0-config package#1554
Conversation
|
I think the first approach is probably cleaner and matches what we do in the Debian packages. Though it would be nice to get rid of the whole Python source tarball step (I remember Michael or Ro working on that a long time ago but don't remember why we got stuck) On naming, I think just |
|
I think removing the tarball would probably make option 1 a bit easier tbh. I'll look into it. |
See #1565 for build logic that removes the need for "python sdist".
Why would we not just create a separate spec file, one per package? If we're creating a new package |
3 participants
WIP - this builds a dummy package
securedrop-admin-dom0-configvia the project's existing.specfile.After investigation, it looks like there are two potential approaches to organizing the specfile to support multiple packages, the first being to have a null parent package that doesn't generate an rpm but sets common fields like License:
The other approach (followed in this PR) is to build the existing
securedrop-workstation-dom0-configRPM as the parent package and just add additional ones:In the second approach, admin RPM files should be added to the Python MANIFEST.in so they get included in the source tarball used to populate
rpm-build/BUILD. After that, how they're structured is up to the%installand%files <package>section.Which we pick is really a matter of taste. If we did decide to split out the updater to its own RPM as a potential requirement for both the workstation and admin config packages, it might be worth trying the first approach. But for just one additional RPM, the second approach works fine.